forked from prusa3d/PrusaSlicer
-
-
Notifications
You must be signed in to change notification settings - Fork 519
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix small area infill flow compensation (graph version) causing some lines to not extrude (#4374) #4399
Open
TheSlashEffect
wants to merge
5,873
commits into
supermerill:nightly_dev
Choose a base branch
from
TheSlashEffect:chka.fix.small-area-infill.graph.4374
base: nightly_dev
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Fix small area infill flow compensation (graph version) causing some lines to not extrude (#4374) #4399
TheSlashEffect
wants to merge
5,873
commits into
supermerill:nightly_dev
from
TheSlashEffect:chka.fix.small-area-infill.graph.4374
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- fix value of branch diameter angle of the organic support - fix overhang speed values
Turn off feature 'use_surface' for new text object
update snapmaker profiles
…reported in prusa3d#11721. The temporary variable used for reordering ExPolygons wasn't cleared, and it contained empty ExPolygons from previous reordering. This caused those empty ExPolygons replaced actual ExPolygons for infill. Another issue was that m_fill_expolygons was reordered, but m_fill_expolygons_bboxes were left untouched.
. arcs merged into a new structure (ArcPolyline)
Signed-off-by: Kristian Nielsen <[email protected]>
…ence the warning. The warning was there because std::string_view::data() returns a pointer to a buffer that is not necessarily null-terminated. So, strncpy shouldn't be used on non-null-terminated buffers, but we always relied only on the buffer length, so it couldn't cause any issues.
Actually, all those deprecated functions were internally called those new functions. So there isn't any risk to use them directly.
…ed() in Arc Welder.
…re there just for debugging purposes.
This variable hasn't been used since the beginning.
…_progress() inside check_objects_after_cut().
…3r::GUI::GUI_App class.
…te_compatible_internal(). This variable hasn't been used since the beginning.
…nymous> may be used uninitialized in this function). This warning was shown because the previous code was triggering a bug in GCC. More about the bug can be found here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465.
force automake 1.16 for macos, as mpfr need at least the 1.16
* overhangs_bridge_threshold * overhangs_bridge_upper_layers * perimeters_hole * support_material_bottom_interface_layers
- Make the input range checks consistent with start_idx, end_idx of existing implementation - Make default extrusion factor 1.0f to prevent similar issues - Small readability improvements
supermerill
force-pushed
the
nightly_dev
branch
from
September 30, 2024 07:40
787415d
to
5dc2ae8
Compare
Thanks, merged. |
supermerill
force-pushed
the
nightly_dev
branch
8 times, most recently
from
October 15, 2024 10:17
97361d8
to
2aea702
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello 3D printing crew
I found the issue that the user was presenting in #4374. The problem was that the actual graph points data structure and
begin_idx
,end_idx
usage were inconsistent in this function. As a result, all extrusion lengths above the max value we account for in the graph (~3.0mm in our case) were not interpolated and got a multiplication factor of 0 instead (the default in this function). I am not sure why the graph implementation works as it does but these changes make this function comply with how the graph and its data structures are currently implemented.Below is the user's scenario as an example, working as expected.
Additional fixes:
y_value
to 1.0f, so the default behaviour leaves the extrusion value as it was.(I): This can cause some discrepancies if we have 2 lines with very close but not equal lengths, as they will both get assigned the same extrusion factor. We could remove this check or make it compare from the left side only, but then again it is a small performance optimization. I leave this decision to the owner :)
(II): A question on the feature; should the feature's function not be monotonically non-decreasing? I personally cannot think of a case where a shorter line should extrude more than a longer one.